Hi, thanks for having a look at this.

My approach with this kind of thing has been that invalid ADM data should result in errors, and to provide tools to fix files that have common issues. This way, users can still render invalid files, but it needs to be clear that they are invalid and should be fixed before they are used in downstream processes.

The question then is whether this is valid or not; i think it's unclear:

• BS.2076-1 and BS.2076-2 clearly state that this is invalid. This is supposed to be a renderer for BS.2076-1 content, though in practice -0 and -1 are similar enough that -0 content should be supported. The changes in -1 are mostly fixes to issues found in -0.
• BS.2076-0 doesn't explicitly rule this out, but:

  • The purpose of the pack/channel format reference is clear:

    Its main use is to deal with non-PCM encoded tracks, where one or more audioTrackFormats must be combined to represent a decodable signal that covers several audioChannelFormats (by referencing an audioPackFormat).

  • All the examples only have an audioChannelFormatIDRef (except for examples using coded formats, where the audioPackFormatIDRef is used instead).

For this particular issue the meaning is clear, but these files have other problems, some of which do cause incorrect rendering (e.g. un-labelsd LFE DirectSpeaker channels), and I'd like to fix all these at the same time to avoid people thinking that they work when they actually don't.

I've set out the approach I think we should take previously in #39 . Hopefully I can find some time to work on this, but i'm not sure.

Maybe I get it wrong... This sounds to me related to the well-known issue with any 'Dolby ADM' (which is an 'special flavour' of BS.2076-0), regardless with which 'Dolby-ADM-compatible' tool it's created (DAW or DaVinci Resolve NLE).
In a similar case we were able to solve the EAR rendering issue running the Dolby-ADM first through an EAT (EBU ADM Toolbox) which is available here:
https://github.com/ebu/ebu-adm-toolbox, using the 'fix_dolby' process
(c.f. https://ebu-adm-toolbox.readthedocs.io/en/latest/example_configs.html)
Mind that after that the ADM won't be accepted neither by any Dolby ADM tools nor for re-importing in related DAW, NLE.
Dolby has been informed about their 'ADM peculiarties' early on. However any concession or fix is pending.

Thanks for this tip, hadn't known about the toolbox @WernerBleisteiner . Are you perchance on a Mac, having the hardest time, granted the C world is not my forté. I created an issue:
ebu/ebu-adm-toolbox#12

Ah. Sorry @JohnnyMarnell. I'd forgotten that EAT runs not on Mac, although it's is my main tool, too.
Accompanying ADM developments on various levels, I've delved into Linux as well, running it on VNC.
But thanks for getting up an issue. Let's hope BBC R&D will keep their excellent ADM and audio staff in their current lay-offs.

Ah good to know, appreciate that @WernerBleisteiner, and seconded on lay-off sparing hopes. I was canned from Spotify in 2023. I have played with some cross compiling via Docker before, to some success. If I find time, I'll keep you (and EBU community) posted.